API Gateways vs Service-meshes
Tags: apigateway, api, servicemeshs
Published: 2023-10-17 14:33:19

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.


![API Gateway high level overview](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9lsn9fwqdgt21x1ru5dp.png)

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 <u>limites</u>.

## 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](https://konghq.com/blog/engineering/jwt-kong-gateway)
- Request routing
- [Traffic splitting](https://cloud.google.com/appengine/docs/admin-api/migrating-splitting-traffic#:~:text=Traffic%20splitting%20distributes%20a%20percentage,of%20traffic%20to%20multiple%20versions.)
- [Canary releasing](https://docs.solo.io/gloo-edge/latest/guides/traffic_management/destination_types/canary/)
- [Traffic shadowing](https://docs.solo.io/gloo-edge/latest/guides/traffic_management/request_processing/shadowing/)
- [Rate limiting](https://docs.solo.io/gloo-edge/latest/guides/security/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.


![Gateways e service mesh em ação](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a5n8wx0q825sit3auo3i.png)


Conforme mostrado na figura, a _service-mesh_ é usada juntamente com a maioria das implementações de serviços como um [sidecar](https://medium.com/microservices-in-practice/service-mesh-for-microservices-2953109a3c9a) 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? 

<u>Algumas funcionalidades são:
</u>

- 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.