API Gateways vs Service-meshes

Um gateway de API desempenha o papel de “abstrair detalhes” e desacoplar implementações. Ele fornece uma abstração coesa em todos os serviços em uma arquitetura de aplicativo como um todo.

Os gateways de API residem acima dos aplicativos/serviços, independentemente da existência de uma service-mesh e fornecem uma abstração para outros grupos. Eles fazem coisas como agregar APIs, abstrair APIs e expô-las de maneira diferente da implementada, além de adicionar políticas de segurança de zero-trust mais sofisticadas na borda com base no usuário. Os problemas nos limites de uma arquitetura de aplicação não são os mesmos dentro desses limites.

Desacoplamento de limites

Uma funcionalidade principal do API Gateway é fornecer uma interface API estável para clientes fora dos limites, parafraseando “API Gateway pattern” do livro Microservices Patterns:

simplificando explicitamente a chamada de um grupo de APIs/microsserviços emular uma API coesa para um “aplicativo” para um conjunto específico de usuários, clientes ou consumidores. A chave aqui é que o API Gateway, quando implementado, se torna a API para clientes como um único ponto de entrada para a arquitetura do aplicativo.

Outro principal objetivo de usar o gateway de API é expor seus (micro) serviços como APIs gerenciadas. Portanto, os serviços API ou Edge que desenvolvemos na camada de API gateway atendem a uma funcionalidade de negócios específica.

• Os serviços API/Edge chamam os microsserviços downstream (compostos e atômicos) e contêm a lógica de negócios que cria composições/mashups de vários serviços downstream.
• Os serviços API/Edge também precisam chamar os serviços downstream de maneira resiliente e aplicar vários padrões de estabilidade, como Circuit Breakers, Timeouts, Load Balancing/Failover. Portanto, a maioria das soluções de gateway de API disponíveis no mercado possuem esses recursos integrados.
• Os gateway de APIs também vêm com suporte integrado para descoberta de serviço, análise (observabilidade: métricas, monitoramento, distributed logging, distributed tracing) e segurança.
• Os gateway de APIs trabalham em estreita colaboração com vários outros componentes do ecossistema de gerenciamento de API, como marketplace/store de API e portal de publicação de API.

Vamos ver as áreas onde os recursos de um gateway de API e de uma service-mesh parecem se sobrepor, mas ambos lidam com o tráfego de aplicativos. A listagem a seguir enumera alguns dos recursos sobrepostos:

• Telemetry collection
• Distributed tracing
• Service discovery
• Load balancing
• TLS termination/origination
• JWT validation
• Request routing
• Traffic splitting
• Canary releasing
• Traffic shadowing
• Rate limiting

A figura abaixo ilustra a coexistência de gateway de API e service-mesh, alguns recursos sobrepostos (como Circuit Breakers, etc.) mas é importante compreender que esses dois conceitos atendem a requisitos fundamentalmente diferentes.

Conforme mostrado na figura, a service-mesh é usada juntamente com a maioria das implementações de serviços como um sidecar e é independente da funcionalidade comercial dos mesmos.

Por outro lado, o gateway API hospeda todos os serviços API (que possuem uma funcionalidade de negócios claramente definida) e faz parte da funcionalidade de negócios da sua solução. O gateway de API pode ter recursos integrados de comunicação entre serviços, mas isso não impede que ele use service-mesh para chamar serviços downstream (gateway de API -> service-mesh -> microservices).

No nível de gerenciamento de API, você pode usar recursos integrados de comunicação entre serviços do gateway de API ou o gateway de API pode chamar serviços downstream por meio da service-mesh, descarregando funções de rede de aplicativos para a malha de serviço.

Do ponto de vista da funcionalidade, o que um API Gateway precisa suportar? E quais casos de uso reais as empresas veem que exigiriam um API Gateway?

Algumas funcionalidades são:

• Request / response transformation
• Application protocol transformation como REST/SOAP/XSLT
• Error / Rate limit custom responses
• Direct responses
• Precise control over api/proxy pipelining
• API composition/grouping

Vamos ver cada um deles!

Request / response transformation

Como parte da exposição de uma API em um gateway de API, você pode ocultar os detalhes de como a API de back-end é implementada. Isso pode ser uma combinação de alteração do formato da solicitação, remoção/adição de cabeçalhos, inserção de cabeçalhos no body ou vice-versa. Isso fornece um bom ponto de dissociação dos clientes quando os serviços de back-end estão fazendo alterações na API ou quando os clients não conseguem atualizar tão rápido quanto o provider.

Application protocol transformation like REST/SOAP/XSLT

Muitas empresas investem em tecnologia como XML sobre HTTP, SOAP ou JSON sobre HTTP. Eles podem desejar expô-los com uma API mais restrita e client-specific e continuar a ter interoperabilidade. Além disso, os provedores de serviços podem querer aproveitar as vantagens de novos mecanismos RPC, como gRPC, ou protocolos de streaming, como rSocket.

Error / Rate limit custom responses

A transformação de solicitações de serviços upstream é um recurso vital de um API Gateway, mas também o é a personalização de respostas provenientes do próprio gateway. Os clientes que adotam a API virtual do API Gateway para tratamento de solicitações/respostas/erros esperam que o gateway personalize suas respostas para se adequar a esse modelo também.

Direct responses

Quando um cliente (confiável ou não) solicita um recurso que não está disponível ou é impedido de ir upstream por algum motivo, é melhor poder encerrar o proxy e responder com uma resposta pré-definida.

Precise control over Proxy pipeline

Não existe uma expectativa única de proxy que atenda todas as demandas possíveis. Um API Gateway deve ter a capacidade de alterar a ordem em que seus recursos são aplicados (rate limiting, authz/n, routing, transformation, etc.), bem como oferecer uma maneira de depurar quando algo dá errado.

API composition

A exposição de uma abstração sobre vários serviços geralmente traz a expectativa de combinar várias APIs em uma única API. Algo como GraphQL.

Controle rígido sobre o que é permitido dentro/fora dos serviços

Outra funcionalidade importante de um API Gateway é “governar” quais dados/solicitações são permitidas na arquitetura do aplicativo e quais dados/respostas são permitidas. Isso significa que o gateway precisará de um conhecimento profundo das solicitações que chegam à arquitetura ou das solicitações que saem.

Por exemplo, um cenário comum é o WAF para evitar ataques de injeção de SQL. Outra são as técnicas de “prevenção contra perda de dados” para evitar que SSN ou PII sejam retornados em solicitações de PCI-DSS/HIPPA/GDPR/LGPD. O edge é um lugar natural para ajudar a implementar essas políticas.

*Novamente, definir e aplicar esses recursos não é tão simples quanto apenas permitir o tráfego HTTP em um cluster.
*

Segurança personalizada/bridging de domínios confiáveis

A última funcionalidade importante que um API Gateway deve oferece é a segurança de borda. Isso envolve desafiar usuários e serviços que existem fora da arquitetura do aplicativo a fornecer políticas de identidade e escopo para que o acesso a serviços e funcionalidades de negócios específicos possa ser restrito. Isso está relacionado à seção anterior.

Um exemplo comum é ser capaz de vincular fluxos OAuth/SSO, incluindo Open ID Connect. O desafio destes “padrões” é que eles podem não ser totalmente implementados ou implementados incorretamente. O API Gateway precisa de uma forma de se adaptar de forma flexível a esses ambientes, além de fornecer personalização.

Em muitas empresas já existem mecanismos de identidade/trust/auth e uma grande parte delegada ao API Gateway é ser capaz de prover integração nativa para compatibilidade com versões anteriores.

Embora novos padrões como o SPIFEE tenham surgido, levará algum tempo para que as empresas os adotem e, enquanto isso, um API Gateway (mesmo um para aplicativos executados em sua arquitetura de next-generation) é um requisito difícil. Isso também está relacionado ao ponto de transformação/desacoplamento feito acima.

Para finalizar, os gateways de API têm uma sobreposição com a malha de serviço em termos de funcionalidade. Eles também podem ter uma sobreposição em termos de tecnologia utilizada (por exemplo, Envoy). No entanto, suas funções são um pouco diferentes, e entender isso pode poupar muito trabalho à medida que você implanta suas arquiteturas de micros serviços e descobre suposições não intencionais ao longo do caminho.