Introdução

Desenvolver plataformas web/mobile, que foram implementadas usando um desenho Arquitetural baseado em Serviços, está se tornando um Mantra dentro das empresas ao redor do mundo. Inicio, aqui, com um sugestão: Tenha visão analítica e corporativa, pois você terá que trabalhar sobre algumas desvantagens, diante de suas escolhas. Você e sua empresa estão prontos para assumir e colher os resultados sobre as suas escolhas?

As Empresas, estão buscando trabalhar de diversas formas, em busca de entregar a implementação e entrega (muitas vezes, “By the Book”) de Serviços/Microsserviços. Devido essa corrida, incessante, para trabalhar sobre esse tipo de estrutura em plataformas web, as empresas estão dividindo suas equipes em divisões de times; onde  há equipes de desenvolvimento especializadas em áreas específicas de negócio, desenvolvendo diversos serviços e APIs, criando um ecossistema computacional complexo, como o cenário apresentado na Parte 1 desta série sobre API Gateway.

Solução utilizando API GatewayUntitled Diagram-API w_ API Gateway

Como pode ser observado no diagrama acima, um API Gateway tem a responsabilidade de rotear, compor/agregar, traduzir protocolo, integrar servidores de segurança, cache de dados, monitorar outras funções inerentes dessa plataforma. Toda requisição dos clientes, tem que passar, a partir de agora, por uma espécie de “Portão” ou API Gateway.

A responsabilidade de um API Gateway, não é apenas rotear a requisição feita por um cliente para um determinado serviço/microsserviço e retornar o Downstream Response de volta para o cliente por meio de um Upstream Response. Existem outras funcionalidades que estão disponíveis nas plataformas/frameworks que implementam esse padrão.

Utilizar um API Gateway, cria a capacidade em uma arquitetura baseada em serviços, a aplicar composição/agregação de dados, através de requisições feitas aos serviços disponíveis no backend. Isso possibilita consumir diversos serviços do seu backend, os quais retornarão dados e estes dados serão enviados como resposta ao API Gateway.

O conjunto de informações retornadas por esses serviços de backend,  passarão por um processo de composição/agregação, ou seja, um processo que irá compor essa estrutura de dados, em uma estrutura final, bem definida e padronizada, como resposta aos clientes requisitantes deste conjunto de informação. Além disso, um API Gateway pode traduzir requisições que utilizam protocolos diferentes, como: HTTP, Web Socket, SOAP, protocolos internos do ecossistema e que não são tão amigáveis para uma UI Web.

Um API Gateway pode, ainda, fornecer uma camada de roteamento customizada para cada um dos diversos tipos de clientes (Desktop, Web, Mobile) candidatos a consumir serviços de backend.

API Gateway: Benefícios e Preocupações

Benefícios

Como se pode observar, o maior benefício do uso de um API Gateway, dentro da sua Arquitetura de Serviços e infraestrutura, é a capacidade de assumir o encapsulamento de estruturas de dados internas da aplicação (estruturas de dados internas dos diversos serviços de backend, que são consumidos pelo API Gateway), ao invés dos clientes consumirem os diversos serviços, consumindo serviço a serviço (aumento do round-trip). Com isso, essa padrão favorece os clientes, tendo um único ponto de contato com com os serviços de backend, ou seja, apenas acessam o API Gateway.

Por ser o único ponto de entrada e saída de dados da infraestrutura de serviços, um API Gateway reduz o número de round trips (número de idas a infraestrutura de serviços) entre os clientes e a infraestrutura que expõe os serviços. Isso, agrega um aspecto importante que é a simplificação de código do lado cliente.

Abaixo, seguem outros benefícios:

  • Escalabilidade;
  • Uso de Programação Reativa;
  • Descoberta de Serviços (Service Discovery);
  • Chamada de Serviços (Service Invocation);
  • Gerenciamento de falhas eventuais.

Desvantagens

Como toda escolha traz uma consequência, o famoso “trade-off”, implementar um API Gateway nos leva a outro nível de desenvolvimento, entrega e gestão de deployment de serviços. Existe o risco de um API Gateway tornar-se um gargalo (bottleneck) – Mas existem técnicas para mitigar eventuais de baixa performance.

Os desenvolvedores são os responsáveis por atualizar um API Gateway, em função de expor os endpoints dos serviços que serão mapeados e roteados – tem que ter bastante atenção e responsabilidade sobre a atualização dessa infraestrutura. Esse tipo de arquitetura de solução, exige que se tenha um processo de devops amadurecido, pois a gestão de atualização desse tipo de infraestrutura, deve acontecer de forma fácil e que possibilite executar um  rollback sem muita dor de cabeça e, também, seja o mais leve possível, de forma a gerar o mínimo de impacto, ou até nenhum impacto, aos clientes que estão consumindo os serviços.

Apesar das desvantagens, perceba que (na minha visão), as dores de NÃO se ter um API Gateway se potencializa a medida que a quantidade de serviços/microsserviços cresce e estes, são disponibilizados em sua infraestrutura de backend que, em aplicações sérias de mercado, faz muito sentido o uso do API Gateway Pattern.

Algumas ferramentas de mercado

Atenção (*)

As ferramentas, marcadas com um asterisco e citadas na seção acima, pertencem à categoria API Managemer, e, portanto, possuem um API Gateway e elementos adicionais como: gestão sobre publicação de APIs, portal do desenvolvedor, dentre outras. API Manager não é tema deste artigo, entretanto, gostaria de salientar que um API Management, pode atuar como um API Gateway, embora o contrário não é verdade. Isso agora fica como assunto para uma nova série no futuro.

Em um próximo artigo, vou mostrar como podemos implementar uma API Gateway, utilizando um framework open-source e concretizar a solução apresentada no post de hoje.

Conclusão

Tendo em vista os aspectos observados neste post, implementar uma Arquitetura baseada em serviços, exige uma série de conhecimentos de engenharia de software e conhecimento para analisar a capacidade computacional, o que nos leva à outros níveis de infraestrutura, monitoramento, gestão de deployment de serviços e aumenta a quantidade de round trips dentro da estrutura de uma plataforma web. O API Gateway Pattern, tem a capacidade de melhorar a comunicação e padronização entre o cliente e o servidor de serviços de backend; implementando o conceito de composição/agregação de serviço, entregando resiliência por meio de recursos que trabalham tolerância a falhas, torna-se o ponto central de monitoramento, autenticação/autorização, ou seja, existem muitos benefícios alcançados quando se faz uso desse padrão, o que torna acietável os pontos de desvantagens e, os conhecendo antecipadamente, pode-se realizar o planejamento adequado para controlá-los.

Referências:

O que achou? Deixe um comentário e compartilhe sua experiência em seus projetos!

Está interessado em desenvolver Arquitetura de Serviço em seus projetos ou melhorar o desenho de sua arquitetura?

A Emerging Code pode te ajudar. Entre em contato conosco, teremos prazer em realizar mentoria em seus projetos!

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s