O que é um gateway federado?

Em sistemas centralizados, um único gateway (conectado e responsável por gerenciar várias APIs) lida com todas as consultas dos clientes. A federação de gateways, por sua vez, permite que uma organização use uma rede distribuída de API gateways, cada um responsável por seu próprio conjunto distinto de serviços.

Em um sistema de gateways federados, as equipes podem adicionar serviços conforme a necessidade sem afetar todo o sistema, permitindo o uso eficiente dos recursos e o gerenciamento do tráfego. Departamentos separados também podem usar protocolos diferentes para gerenciar seus respectivos gateways. O framework dá às equipes a liberdade de gerenciar suas próprias APIs, melhorando a flexibilidade, a resiliência operacional e muito mais.

Essa abordagem também ajuda a evitar gargalos de tráfego e outros problemas associados a API gateways centralizados e pode proporcionar benefícios de desempenho ao implementar funções de gateways mais próximas dos usuários finais. As estratégias de federação de gateways podem ser aplicadas a vários estilos e protocolos de arquitetura de API, incluindo REST, gRPC e SOAP, cada um oferecendo vantagens e desvantagens.

Do ponto de vista da TI, um gateway federado é benéfico porque permite que as equipes de DevOps desenvolvam e implementem suas próprias APIs e, ao mesmo tempo, cumpram as políticas de gerenciamento de plataformas de APIs, governança e segurança de toda a empresa. As equipes podem migrar rapidamente e de forma independente para concluir projetos em seus domínios (facilitando a inovação e acelerando a velocidade de lançamento no mercado) preservando os padrões de toda a organização, encontrando um equilíbrio entre a autonomia da equipe e a supervisão centralizada.

A federação do GraphQL é um conceito alternativo e uma abordagem de arquitetura que é usada para criar uma API GraphQL unificada. Ela se baseia no GraphQL, uma linguagem de consulta que pode direcionar com precisão recursos de vários serviços com uma única consulta de API.

A federação do GraphQL conecta diferentes serviços (conhecidos como subgráficos) — cada um com seu próprio esquema que define os dados que gerencia — a um esquema unificado conhecido como supergráfico. Um único gateway expõe esse esquema de supergráfico às aplicações, une vários serviços e campos subjacentes e encaminha todas as consultas de APIs. Por outro lado, a federação de API gateways conecta vários API gateways por meio de um plano de controle central, com cada API gateway fazendo suas próprias consultas.

Federação é uma abordagem geral para o gerenciamento de sistemas que conecta componentes autônomos por meio de um plano de controle comum.

Em um sistema de gateways centralizado, todas as solicitações de clientes fluem através de um único gateway, que gerencia funções como roteamento, autenticação, autorização e monitoramento. Diferentemente das arquiteturas federadas, essas responsabilidades não são distribuídas entre várias instâncias.

Essa abordagem pode simplificar o registro, o gerenciamento de tráfego, a imposição de segurança e outras tarefas, pois cada um desses processos flui pelo gateway. As organizações também podem iniciar implementações a partir de um único ponto, eliminando a necessidade de atualizações de versões em vários gateways e serviços.

No entanto, empresas com frameworks centralizados podem ter maior probabilidade de encontrar gargalos, especialmente à medida que expandem suas operações. Como o único ponto de passagem do sistema, o gateway pode facilmente ficar congestionado. Além disso, ele apresenta um único ponto de falha; se ocorrer um erro, ele afetará todo o sistema.

Diferentemente dos sistemas centralizados, as arquiteturas de gateways federados são compostas por vários gateways, cada um responsável por um conjunto distinto de serviços e APIs associadas. Os gateways funcionam de forma independente, embora cada um seja gerenciado por um plano de controle central.

Em comparação com os frameworks centralizados, os sistemas federados promovem flexibilidade e autonomia, dando às equipes de desenvolvimento um maior nível de controle sobre seus respectivos domínios. Esse layout descentralizado também torna os sistemas federados mais resilientes contra interrupções e falhas de sistema.

No entanto, os sistemas federados são operacionalmente mais complexos, o que pode introduzir disparidades de governança e falhas de comunicação entre as equipes. Os lançamentos podem levar mais tempo, e a manutenção pode ser mais cara, porque cada gateway deve ser gerenciado e atualizado separadamente.

Há várias razões pelas quais uma empresa pode optar por um sistema de gateways federados.

Por um lado, a federação de gateways é comumente usada em casos de fusões e aquisições, nos quais uma empresa herda diferentes stacks de tecnologia e sistemas de API management das empresas que adquire. Em vez de gerenciar individualmente várias arquiteturas separadas (cada uma com protocolos de segurança, padrões técnicos e estruturas de governança distintos) ou de tentar adaptar os sistemas adquiridos aos sistemas empresariais existentes, as empresas recorrem à federação de gateways. Essa abordagem permite que as organizações incorporem os API gateways existentes e seus sistemas subjacentes na estrutura sobreposta fornecida pelo plano de controle central.

Da mesma forma, vários gateways são frequentemente usados em ambientes com muitos microsserviços construídos por diferentes equipes e espalhados por diferentes cenários. Uma empresa também pode escolher um sistema federado para obter benefícios de desempenho.

Por exemplo, considere uma empresa de logística com vários escritórios em todo o mundo, cada um atendendo a uma região específica. Ao colocar gateways, servidores, serviços e outros recursos mais próximos dos clientes que os acessam, a empresa pode otimizar a latência e os fatores de desempenho relacionados.

Na federação de gateway, o plano de controle central lida com gerenciamento, monitoramento e governança, mas geralmente é inacessível aos clientes. Os consumidores de APIs interagem diretamente com os gateways que compõem o sistema federado (consultando o endpoint responsável pelos serviços relevantes), mas não consultam o próprio plano de controle. O plano recebe metadados e registros somente após a ocorrência de uma chamada de API.

Embora essa abordagem possa introduzir alguma complexidade operacional, ela também promove a independência. Por exemplo, ajuda a permitir que as equipes de plataformas configurem seus próprios gateways e serviços para atender às suas necessidades específicas, escolher seus próprios protocolos e implementar lançamentos por conta própria. As arquiteturas federadas também são mais resilientes a configurações incorretas e violações de segurança, porque os erros são isolados no gateway de onde se originaram e, provavelmente, não se espalharão para outros gateways na rede.

Enquanto isso, na federação do GraphQL, os esquemas de vários serviços independentes (subgráficos) são combinados em um esquema de supergráfico unificado. Um único gateway, ou roteador, apresenta um único ponto de entrada para consultas de clientes, proporcionando uma experiência de API unificada.  

O roteador divide as consultas de forma inteligente em subsolicitações menores, recuperando informações relevantes de vários subgráficos e compilando-as em uma resposta coesa para os clientes.

Imagine uma plataforma de saúde com serviços separados para:

• Pacientes: gerenciamento de detalhes de pacientes, informações de contato e históricos médicos
  
  
• Compromissos: agendamento e acompanhamento de próximas consultas
  
  
• Faturamento: manuseio de faturas e notificações de faturamento

Em vez de consultar cada um desses endpoints com uma chamada de API separada, a federação do GraphQL apresenta uma interface unificada que permite aos clientes (nesse caso, um aplicativo ou dashboard que atende médicos ou pacientes) acessar o histórico médico de um paciente, identificar sua próxima consulta e determinar seu saldo devedor com uma única chamada de API, em vez de por meio de três solicitações separadas.

A federação do GraphQL oferece uma maneira de criar uma API do GraphQL escalável em um ambiente distribuído. O framework permite o desenvolvimento e a implementação independentes de serviços e, ao mesmo tempo, fornece uma interface unificada para as consultas dos clientes. No entanto, a federação do GraphQL pode ser propensa a desafios de custo e complexidade, vulnerabilidades de segurança, congestionamentos e redundâncias.

Lançada em 2019, a federação Apollo é uma implementação da federação do GraphQL que usa diretivas especiais (como @key ou @extends) dentro da linguagem de definição de esquema do GraphQL para definir relacionamentos entre diferentes tipos em subgráficos.

Embora o Apollo seja uma solução comum, não é a única opção de federação do GraphQL disponível. Alternativas comuns incluem Hive, Mesh, Indigo e WunderGraph Cosmo, cada uma oferecendo diferentes níveis de personalização. 

Embora menos de 5% das empresas tivessem sistemas de GraphQL federados em 2024, espera-se que esse número chegue a 30% até 2027, de acordo com a empresa de pesquisa Gartner. Os principais provedores de nuvem, como Amazon Web Services (AWS) e Microsoft Azure, bem como repositórios de código como o GitHub, também são compatíveis com APIs GraphQL com ferramentas integradas de observabilidade e validação.

A federação do GraphQL tem várias vantagens distintas, especialmente em sua capacidade de simplificar o acesso às APIs para clientes. As equipes podem manter um grau de independência ao implementar, gerenciar e escalar seus próprios subgráficos.

Mas, como um framework centralizado, a federação do GraphQL é mais vulnerável a falhas de segurança, problemas de congestionamento e ineficiências de desempenho. Também está presa a esquemas do GraphQL, enquanto a federação de API gateways é compatível com vários protocolos.

Ao desenvolver uma estratégia de APIs, as organizações decidem se desejam adotar um framework de API GraphQL ou usar outro estilo de arquitetura, como REST, para suas APIs.

No final das contas, as organizações podem optar por incorporar a federação do GraphQL e outros estilos de arquitetura em seus sistemas, sendo que cada um é responsável por lidar com diferentes funções. Em uma configuração comum, uma empresa usa o GraphQL internamente (com proteções rígidas para reduzir as preocupações com segurança, custo ou complexidade) e usa um estilo de arquitetura diferente, como o REST (que pode proporcionar um nível mais profundo de controle e uma adoção mais fácil) para APIs externas. Nesse cenário, um API gateway federado também pode ser usado para unificar esses estilos arquitetônicos díspares por meio do plano de controle central.

Em configurações de API gateways padrão, um único gateway lida com todo o tráfego de usuários, roteamento e análise de dados. Embora essa abordagem ajude a agilizar configurações mais simples, ela pode rapidamente levar a gargalos em ambientes mais complexos.

Os gateways federados dependem não de apenas um único API gateway, mas de uma variedade deles. Cada gateway é usado para gerenciar chamadas de APIs para um conjunto específico de serviços, e os gateways são conectados ao plano de controle, que lida com o gerenciamento e a governança.

As malhas de serviço, por sua vez, são consideradas configurações leste-oeste porque gerenciam conexões entre microsserviços, mas não interagem com os próprios usuários. As malhas de serviço facilitam principalmente a comunicação e a observabilidade em um único ambiente ou cluster. No entanto, variantes conhecidas como malhas de nuvem híbrida são otimizadas para executar funções como criptografia, balanceamento de carga e autenticação em vários clusters e ambientes (incluindo ambientes multinuvem, de nuvem híbrida e locais). 

As organizações podem usar várias estratégias para aproveitar a arquitetura distribuída de um gateway federado e, ao mesmo tempo, reduzir algumas das complexidades operacionais e custos de manutenção associados aos sistemas federados. Essas práticas ajudam a preservar a autonomia da equipe e,ao mesmo tempo, manter linhas abertas de comunicação e supervisão unificada entre as equipes.

As empresas devem fazer distinções claras entre as equipes, eliminando ambiguidades em torno de quais serviços cada uma é encarregada de construir e manter. Essa prática promove a responsabilidade e protege as equipes de duplicar ou configurar erroneamente o trabalho dos colegas. Por extensão, essa abordagem pode aumentar a produtividade porque as equipes têm uma compreensão firme de seus objetivos e responsabilidades (e a liberdade de agir de acordo com eles).

A implementação inconsistente de protocolos e normas de segurança e conformidade em gateways e APIs pode representar riscos de segurança, legais e de reputação. A manutenção de normas de registro, criptografia, autenticação e outras implementações de segurança ente gateways deve ser uma prioridade em um sistema distribuído. Isso ajuda a garantir que o plano de gerenciamento central possa ser usado para responder com eficiência a relatórios de incidentes, fazer auditorias abrangentes e evitar ataques futuros, independentemente do domínio de origem da ameaça.

Lacunas de observabilidade em um sistema distribuído podem levar a riscos de segurança e problemas de desempenho. É crucial que o plano de gerenciamento central forneça a visibilidade abrangente necessária para que as equipes visualizem a integridade e o desempenho do sistema. Esse recurso ajuda a permitir uma remediação rápida quando surgem problemas, bem como a capacidade de fazer melhorias proativas com base em métricas de segurança e desempenho.

Os portais do desenvolvedor unificados atuam como hubs centralizados onde os desenvolvedores podem acessar e aprender sobre qualquer API no sistema, independentemente de onde estejam hospedadas ou como estejam estruturadas. Eles são especialmente importantes em sistemas federados porque fornecem diretrizes, documentação e exemplos de programação para oferecer às equipes de DevOps um framework claro de como suas APIs devem ser construídas, implementadas e mantidas.

Essas normas universais, juntamente com chaves de APIs e outros controles de acesso, ajudam a garantir que os desenvolvedores possam adicionar APIs ao sistema sem dificuldades e gerenciar seus próprios gateways, mantendo a segurança e a consistência.

Como cada equipe atua com certo grau de autonomia, linhas abertas de comunicação são vitais para compartilhar melhores práticas e manter uma rede sustentável. Os dashboards e outras ferramentas de colaboração podem ajudar as equipes a se sincronizar em torno de metas e procedimentos compartilhados, especialmente quando uma alteração em um domínio pode afetar os serviços relacionados.

Mecanismos abrangentes de geração de relatórios permitem que as equipes de DevOps detectem e lidem com a latência, as interrupções no serviço e outras anomalias, contribuindo para uma experiência de usuário mais perfeita. As métricas de desempenho também podem melhorar a eficiência da escala ao identificar quais partes do sistema estão atingindo a capacidade e quais estão com baixo desempenho.

Abordagens modernas de DevOps, como infraestrutura como código (usando código para automatizar processos de TI que, de outra forma, exigiriam supervisão manual e provisionamento) e AIOps (usando IA para simplificar operações de TI) podem ajudar gateways federados a operar de forma mais eficiente. As técnicas de automação também contribuem para uma rede mais resiliente, pois reduzem a probabilidade de erros humanos e dão às equipes de TI largura de banda para se concentrar em problemas mais complexos.

A federação de gateways combina a flexibilidade e a personalização de arquiteturas descentralizadas com uma estrutura de governança centralizada e pode oferecer várias vantagens em relação às arquiteturas tradicionais.

A federação dá às equipes controle sobre seus próprios gateways, permitindo que ajustem configurações de tempo de execução, gerenciem atualizações e personalizem ambientes de programação para melhor atender às necessidades de seus clientes e serviços. Por exemplo, para ajustar o limite de taxa de uma API em um sistema centralizado, uma equipe precisaria enviar uma solicitação por meio do gateway único da organização. Os sistemas federados permitem que as equipes façam o ajuste de forma independente e em tempo real, sem afetar outros gateways na rede.

O plano central ajuda a garantir que vários gateways, apesar de terem suas próprias configurações, obedeçam aos padrões compartilhados de compatibilidade e segurança. As equipes têm flexibilidade para ajustar parâmetros de forma autônoma enquanto se beneficiam do benefício da supervisão externa fornecida pelo plano de controle.

A abordagem federada reconhece que as equipes de desenvolvimento geralmente têm a melhor ideia de como melhorar e manter seus próprios domínios. As equipes têm autonomia para ajustar suas APIs ou serviços assim que identificam um problema surgindo, melhorando a adaptabilidade e a agilidade. 

As equipes podem até mesmo trabalhar em diferentes linguagens de programação enquanto mantêm sua relação de serviço com o plano de controle central. Por fim, os departamentos podem implementar atualizações conforme a necessidade, em vez de depender de uma autoridade central para aprovar alterações, melhorando o tempo de lançamento de novas funcionalidades no mercado e simplificando os fluxos de trabalho.

Os sistemas federados podem oferecer provisionamento de recursos mais eficiente, permitindo que as equipes monitorem seu próprio desempenho e ajustem os limites de taxa e as distribuições de tráfego adequadamente. As organizações podem ampliar apenas os serviços e funções que exigem capacidade extra, canalizando recursos de serviços ou regiões menos utilizados para aqueles com maior demanda.

Além disso, como os API gateways são independentes, é mais difícil que as vulnerabilidades passem de um gateway para outro. Como resultado, os sistemas federados geralmente são mais resilientes contra ataques e falhas, pois é provável que as falhas afetem apenas um único gateway, em vez de todo o sistema.

Em sistemas federados, equipes individuais de DevOps assumem a operação e manutenção de seus próprios gateways. Com menos responsabilidades, a equipe central pode se concentrar em questões de nível superior, como impor regulamentações de conformidade, facilitar a comunicação cruzada entre equipes e refinar arquiteturas de sistemas.

Os silos de dados são muito menos prováveis porque um gateway federado pode analisar o desempenho e impor barreiras em todos os domínios. As métricas de gateways cruzados podem fornecer uma visão mais holística de como um determinado serviço está impactando produtos e serviços relacionados.

A propriedade descentralizada e a flexibilidade podem apresentar vários desafios, especialmente quando há falhas na governança ou na observabilidade. Os desafios introduzidos pelos gateways federados incluem:

Embora a autonomia da equipe possa ajudar a impulsionar a inovação, ela também adiciona complexidade arquitetônica ao sistema, aumentando os custos de infraestrutura e computação. Sistemas federados também tendem a exigir mais recursos de manutenção e segurança devido à sua estrutura descentralizada.

Como as métricas e os logs são distribuídos em vários API gateways, pode ser mais difícil para as organizações criar uma imagem coesa do desempenho geral do sistema. As fontes de dados podem se tornar fragmentadas e desconectadas da rede mais ampla, tornando mais desafiador identificar e solucionar possíveis configurações incorretas. As organizações podem enfrentar esse desafio com protocolos e princípios sólidos de padronização e com ferramentas de observabilidade.

Embora as equipes individuais possam fazer atualizações a seu próprio critério, lançamentos em toda a empresa podem levar mais tempo do que em ambientes centralizados. Em vez de atualizar uma única base de código central, os gateways federados devem distribuir atualizações em vários domínios, com cada equipe responsável por aprovar e integrar essas alterações de forma independente.

Manter configurações e políticas consistentes em gateways distribuídos pode representar um desafio. Se as equipes adotarem protocolos, cronogramas de implementação e formatos de dados que se desviem dos padrões de governança corporativa, podem surgir incompatibilidades e vulnerabilidades de segurança. Por outro lado, se as normas e as políticas de governança se tornarem muito rigorosas, as empresas correm o risco de sufocar a experimentação e diminuir o ritmo da inovação. Em um sistema federado, o equilíbrio é crucial.

Conforme as empresas crescem e evoluem sob um sistema federado, elas correm o risco de introduzir novas ineficiências, como a expansão de APIs, quando várias equipes desenvolvem involuntariamente APIs redundantes. Se esse problema aumentar, os gateways poderão se tornar incontroláveis, impossibilitando o plano central de rastrear as alterações. Esse problema pode ser mitigado por meio da governança eficiente.