API Gateway: qual sua função e porque utilizar um

Você sabe a importância da adoção estratégica de uma REST API para melhorar a segurança e garantir a escalabilidade das suas aplicações de negócio?

Se você está construindo uma arquitetura de microsserviços, provavelmente já ouviu falar do termo API Gateway. Mas o que é exatamente um API Gateway e por que ele é importante?

Neste artigo, vamos explorar em detalhes a função de um API Gateway e os motivos pelos quais você deve utilizá-lo em sua arquitetura de microsserviços. Desde garantir a segurança das suas APIs até simplificar a comunicação entre seus serviços, esse item pode ser uma peça-chave para o sucesso do seu projeto. Boa leitura!

O que é um API Gateway?

O API Gateway nada mais é do que um gerenciador de tráfego que faz a interface com o serviço de back-end real ou de dados.

Em seguida, aplica políticas, autenticação e controle de acesso geral para chamadas de APIs, com o objetivo de proteger dados sigilosos e importantes.

Por que utilizar um API Gateway?

Basicamente, é uma das formas de controlar o acesso aos sistemas e serviços de back-end, o que é ótimo para os clientes que terão uma experiência encantadora.

Além disso, ele ainda garante a escalabilidade e alta disponibilidade dos serviços oferecidos pela sua empresa, sendo o responsável por encaminhar a solicitação ao serviço apropriado e, em seguida, devolver uma resposta ao solicitante.

Qual a sua função?

O API Gateway assegura uma conexão segura entre seus dados e APIs, além de gerenciar o tráfego e as solicitações das APIs, incluindo balanceamento de carga, tanto dentro quanto fora de sua empresa.

Por fim, pode aplicar políticas, autenticação e controle de acesso geral para as chamadas de APIs, como mencionamos acima, a fim de manter os dados seguros.

Como funciona o API Gateway?

Ele recebe as chamadas de API de clientes para, depois, encaminhá-las para o microsserviço correto.

Para isso, utiliza-se o roteamento de solicitação, composição e tradução de protocolo. Explicaremos melhor ao decorrer deste artigo.

Qual a diferença entre ESB e SOA?

Na década de 80, as organizações passaram a investir e procurar formas de agilizar seus processos de negócio alavancados por novas tecnologias.  

Então, surge o conceito de EAI – Enterprise Application Integration, em português, Integração das Aplicações das Empresas, de forma automatizada e com efetividade. 

Por conseguinte, surgem dois conceitos importantes: ESB – Enterprise Service Bus (Barramento de Serviços Corporativo) e SOA – Service Oriented Architecture (Arquitetura Orientada à Serviços). Entenda! 

Aquelas aplicações departamentais passaram a contar com serviços e programas que executam diversas demandas de forma totalmente automatizada. 

Além disso, proviam informações para que outro programa do mesmo ou de outro setor também pudesse ter acesso. O processo tornou-se mais organizado, menos burocrático e, claro, exigia pouquíssima interação humana.  

O ESB foi uma estratégia em que todos esses serviços e dados produzidos ficavam concentrados numa única “via” comum (barramento).  

Isso quer dizer que podiam ser controlados e reaproveitados a partir de um só lugar. Na verdade, as aplicações eram as responsáveis pelo gerenciamento dessa via.  

Já o SOA foi uma abordagem aditiva. O objetivo era exatamente organizar o controle desses serviços, estabelecendo o que conhecemos hoje como governança. 

Virtualização e computação em nuvem

Com o “boom” da expansão da Internet, a integração entre sistemas não se dava mais dentro das empresas.

Desse modo, tanto o ESB como o SOA começaram a apresentar problemas como:

• escalabilidade (desempenho para aguentar uma escala de comunicação agora global);
• amarração (lock-in), existiam poucos vendedores destas tecnologias;
• governança, a medida em que novas funções para aplicações foram surgindo;
• falta de controle adequado de ciclo de vida desses serviços, quantidade, identificar duplicações, maneiras fáceis de uma empresa divulgar como outras poderiam utilizá-los e cobrar por isso adequadamente.

Diante desse cenário, surgiram dois avanços tecnológicos que adicionaram mais energia ao “curto-circuito”: virtualização e computação em nuvem.

Com a virtualização, tivemos uma enorme expansão na quantidade de computadores que executam serviços. Aplicações que antes tinham três ou quatro servidores físicos, agora podem ter 50, 100 virtualizados.

Em meio a essa avalanche de dados, é necessário controlar uma vazão gigantesca de quantidade de transações por segundo (TPS). Imagine que esse poder seja distribuído por regiões e zonas globais. 

Trata-se de áreas onde grandes empresas como Google, Amazon e Microsoft mantêm e administram seus parques computacionais pelo mundo, vendendo o serviço de computação em nuvem (cloud).

Esses avanços empurraram e, ao mesmo tempo, são empurrados pelo modelo de integração mais utilizado no momento: APIs e microsserviços.

Nesse modelo de desenvolvimento e integração, ao contrário dos antigos mainframes centralizadores, temos a premissa de componentizar, desacoplar, expor e monetizar as funções que um negócio realiza.

Ficou complicado de entender? Vamos às explicações no próximo tópico.

Utilização dos APIs e microsserviços no dia a dia

As organizações têm diversos serviços que podem ser oferecidos aos clientes finais e/ou às empresas. Trata-se de funções que uma empresa consegue disponibilizar de forma automatizada e gerenciada.

Ao componentizar uma função de negócio, queremos dizer que é possível separar as funções que serão fornecidas por um ou vários sistemas em conjunto, sem que o consumidor saiba quais são.

Logo, dizemos que essa função virou uma API, que pode ter várias etapas internas, conhecidas como microsserviços.

Dessa forma, tal qual um brinquedo de blocos, é preciso associar componentes diferentes (APIs e microsserviços) para gerar valor a quem consome aquelas funções.

Quando falamos em desacoplar sistemas, significa tornar essas funções de negócio independentes umas das outras e, também, independentes de fabricantes.

Se uma função dessas é fornecida pelo fabricante A, podemos trocar pelo fabricante B com mínimas ou zero adaptações, não há necessidade de recompilar ou refazer os sistemas utilizados.

Expor é sobre integrar! Vamos supor que uma startup crie um serviço inovador de críticas de seriados e, depois, outra gigante de streaming deseja revender esse serviço para os seus clientes.

Como fazer isso de forma eletrônica, automatizada e gerando lucros? Basta que a startup crie essas funções e as publique (exponha-as) numa espécie de portal de Internet.

Os técnicos da empresa de streaming terão acesso ao portal, podendo consultar o modo de uso, formas de solicitar uma crítica e formatos de respostas possíveis.

Depois, contratam a startup e começam a pagar pelo uso dessas APIs e microsserviços.

Isso é o que chamamos de monetização de APIs, que deu origem ao termo de  API Economy.

Basicamente, fez com que diversas organizações entendessem o potencial de seus serviços, vendendo-os para outras empresas, em um regime de pagamento por consumo.

Essas vantagens da integração moderna trazem alguns desafios:

• Como expor as APIs?
• Como ter um catálogo delas?
• Como gerenciar seu ciclo de vida, desde a ideia de negócio até sua descontinuidade?
• Como conseguimos monitorá-las, sendo proativo antes da ocorrência de incidentes?
• Como gerar insights de acordo com o seu uso?
• Como monetizar e controlar a receita gerada pelo consumo?

A resposta disso tudo vem a partir de uma solução de Manager, que permite fazer coisas como:

• Conceber APIs desde a geração da ideia até sua implantação, governando seu ciclo de vida
• Controlar essas APIs, independentemente de onde estejam (em uma ou várias clouds, no data center do cliente, híbridas, etc.)
• Publicar num Portal do Desenvolvedor e documentar todas as funções, objetivos, formas de requisição e retorno das APIs
• Tornar o desenvolvimento de APIs colaborativo, ou seja, vários profissionais de uma organização, desde negócio até operações poderão contribuir na confecção dessas funções, quebrando silos e agilizando o tempo de projeto, codificação, testes e entrega
• Monitorar e controlar o desempenho e a disponibilidade das APIs e microsserviços, gerando alertas para anomalias e criando relatórios analíticos que gerarão insights importantes para a evolução do negócio.

Como pode ser notado, um API Gateway veio para quebrar barreiras entre os mais diversos setores de uma empresa. Além disso, o sucesso de seus aplicativos também depende dele.

Tenha em mente que só um gateway pode garantir um ótimo desempenho, alta disponibilidade e escalabilidade de seus serviços.

O que é a plataforma DHuO API

É uma plataforma de gerenciamento e governança de todo o ciclo de vida das APIs de uma organização, desde o momento do design até o monitoramento. A plataforma DHuO API é uma solução de gerenciamento, governança, e monitoramento e otimização de APIs. Entre seus recursos estão:

• Funcionalidades de design de API de baixo código;
• Monitoramento eficiente de APIs;
• Implementação de programas especializados em API corporativa;
• Portais personalizáveis;
• Versionamento de especificações de APIs;
• Motor de execução de API seguro e performático;
• Gerenciamento de multi-gateways;
• Automação de deploys em vários ambientes de execução.

A presença global da Engineering permite uma visão diferenciada da evolução dos negócios digitais. A DHuO API ajuda as empresas a alcançarem um nível de resiliência constante ao superar esses desafios.

Então, que tal facilitar essa jornada agora? Conheça a plataforma DHuO e faça a transformação digital da sua empresa começar de verdade. 

Este artigo foi desenvolvido por Gustavo Bunger, Gerente de Arquitetura de Cloud Solutions na Engineering.